ЭХОПОЛИСИ РЕГИОHА 50 ЗОHЫ 2 FIDONET Версия: 2.0 Принята голосованием координаторов и эхо-хабов R50. Вступила в силу 22 февраля 2005 года =================================== СОДЕРЖАHИЕ 1.0 Введение 1.1 Цель данного документа 1.2 Определения 1.3 Региональный бекбон 2.0 Функционирование на региональном уровне 2.1 Обязанности регионального эхокоординатора 2.2 Hазначение регионального координатора 2.3 Региональные хабы 2.4 Взаимодействие с координаторами FidoNet 3.0 Модераторы конференций 3.1 Признание модераторов 3.2 Обязанности модераторов 4.0 Другие функциональные процедуры 4.1 Технические области 4.2 Технические стандарты сообщений 4.3 Добавление конференций на бекбон 4.4 Удаление конференций с бекбона 4.5 Внешние, межрегиональные и межсетевые конференции 4.6 Финансовые взаимоотношения 4.7 Конференции вне регионального бекбона 5.0 Порядок разрешения конфликтов 6.0 Порядок принятия и изменения эхополиси 6.1 Принятие эхополиси и переходный период 6.2 Внесение изменений в эхополиси 1.0 Введение 1.1 Цель данного документа Данный документ устанавливает политику и процедуры распространения эхопочты в рамках региона 50, а также порядок взаимодействия между участниками регионального эхобекбона. В документе рассматривается только региональный уровень распространения эхопочты. Функционирование сетевых бекбонов может регулироваться сетевыми эхополиси. В сетях региона могут действовать сетевые эхополиси, не противоречащие общей полиси FidoNet и данному документу. Сетевые эхоконференции, принятые на региональный бекбон, подчиняются эхополиси региона. Если сетевая эхополиси отсутствует, то в сети действует эхополиси региона, порядок применения которого определяет NEC (или, в случае его отсутствия, NC) по согласованию с REC. Данный документ не является частью FIDONET Policy. Если какая-либо часть этого документа вступает в противоречие с FIDONET Policy, то действует соответствующее положение Policy. 1.2 Определения Эхомейловая конференция (эхоконференция, конференция) - совокупность сообщений, распространяемых под определенным именем конференции (AREATAG) в соответствии со стандартами FTN-сетей. Подписчик эхоконференции - участник или пользователь сети, получающий сообщения, публикуемые в эхоконференции, а также имеющий возможность помещать туда, если это разрешено, свои сообщения. Региональный бекбон - структура распространения эхопочты, координируемая REC. Бекбон состоит из узлов, участвующих в распространении эхопочты, признающих данный документ и получивших от регионального эхокоординатора статус эхохаба. Сетевой бекбон - структура, аналогичная региональному бекбону, создаваемая и работающая на уровне сети и координируемая NEC или, в случае его отсутствия, NC. Региональный эхокоординатор (REC) - лицо, координирующее распространение эхопочты и соблюдение данного документа в регионе, которому RC делегировал соответствующие полномочия. Региональный бонмастер (RBM) - лицо, координирующее технические вопросы функционирования регионального эхобона, которому RC или REC делегировал соответствующие полномочия. Сетевой эхокоординатор (NEC) - лицо, координирующее распространение эхопочты в своей сети. В случае отсутствия в сети сетевого эхокоординатора его обязанности исполняет NC. Эхохаб (хаб) - утвержденный REC'ом узел, который распространяет эхопочту на другие сети/узлы. Региональные хабы распространяют эхопочту на региональном уровне. Подхабник - совокупность узлов-лонглинков, которые являются точками входа эхопочты в сети. Статус лонглинка узел получает решением REC по представлению соответствующего NC. Список хабов и лонглинков публикуется REC'ом. Модератор - лицо, председательствующее в конференции и отвечающее за соблюдение в ней установленных правил и данного документа. Решения модератора, касающиеся управляемых им конференций, обязательны для всех подписчиков конференции и узлов, распространяющих эти конференции. Решения модератора не могут противоречить FPD и данному документу. Комодератор - лицо, которому модератор эхоконференции делегировал те или иные полномочия в конференции. Если правилами конференции не оговорено иное, комодератор обладает теми же правами, что и модератор, кроме права изменять правила конференции и права назначать, смещать или изменять полномочия модератора и комодераторов. 1.3 Региональный бекбон Участие в эхомейловом бекбоне региона 50 является добровольным. Хабы, узлы, модераторы и комодераторы, принимая участие в работе бекбона, соглашаются выполнять процедуры и предоставлять сервис, описанные в данном документе. Сервис, предлагаемый региональным бекбоном, является дополнением к тому, который обязателен для членов FIDONET согласно FIDONET-policy. Использование этого сервиса следует рассматривать как привилегию, а не как право. Хотя участники регионального бекбона стремятся обеспечить наилучший сервис в распространении эхопочты, никакие гарантии не оговариваются. 2.0 Функционирование на региональном уровне 2.1 Обязанности регионального эхокоординатора Региональный эхокоординатор координирует работу бекбона на региональном уровне. В его обязанности входит: определение структуры и состава регионального бекбона и поддержка его нормального функционирования, определение формата и ведение списка конференций, распространяемых средствами регионального бекбона (эхолиста), ведение архива правил конференций, распространяемых средствами регионального бекбона, определение текущих ограничений, действующих при принятии конференций на бекбон (см. далее п.4.3), определение перечня стандартов, обязательных для соблюдения на региональном бекбоне, а также допустимого объема необязательной служебной информации в сообщениях, разработка и обеспечение совместно с региональными хабами аварийного плана, который используется в случае возникновения непредвиденных проблем у региональных хабов, согласование с NEC (NC) порядка применения эхополиси региона на сетевом уровне в случае отсутствия эхополиси сети, осуществление надзора за проведением выборов модераторов в конференциях регионального бекбона, а также в тех небекбонных конференциях, выборы в которых проводятся с целью принятия конференции на региональный бекбон, разрешение конфликтных ситуаций, описанных в п.5 данного документа. REC вправе делегировать сисопам региона любые свои полномочия, кроме решения вопроса о принятии или удалении конференции с регионального бекбона, а также разрешения конфликтов. 2.2 Hазначение регионального эхокоординатора REC назначается RC из числа сисопов региона по результатам консультации с NC, NEC и эхохабами. В случае, если RC или треть списочного состава региональных хабов, или четверть общего количества NC и NEC сочтут, что REC не справляется со своими обязанностями, RC обязан его заменить. Порядок назначения NEC определяется эхополиси сети, если такой документ существует. При ее отсутствии применяется процедура, аналогичная той, что была описана выше (NC назначает NEC'а с учетом мнений сисопов эхохабов сети). 2.3 Региональные хабы REC определяет (утверждает) региональных хабов для распространения эхопочты на региональном уровне. REC может одновременно являться региональным хабом, если он этого желает и при этом его узел имеет необходимые ресурсы. Каждый региональный хаб обеспечивает минимум одну межсетевую связь. Hа каждом региональном хабе должны быть доступны для передачи на сетевой уровень распространения все конференции бекбона и официальная файлэха бекбона. Каждый региональный хаб делает доступными все конференции бекбона и официальную файлэху бекбона для передачи на сетевой уровень распространения. Региональные хабы обязаны поддерживать аварийный план, который разработан REC и используется в случае появления непредвиденных проблем у одного из них. 2.4 Взаимодействие с координаторами FidoNet Эхокоординаторы и хабы бекбона являются узлами FidoNet и выполняют все решения координаторов FidoNet. Координаторы FidoNet не вмешиваются в деятельность эхокоординаторов и хабов бекбона, пока эта деятельность не нарушает функционирование сети или региона. Конфликтные ситуации, в случае их возникновения, разрешаются вышестоящим координатором FidoNet. 3.0 Модераторы конференций Модераторы председательствуют в конференциях. Участники бекбона не должны вмешиваться во внутренние дела конкретной конференции, пока это не мешает функционированию бекбона. Модератор не обязан быть членом FidoNet (может быть пойнтом или пользователем BBS), но обязан предоставить адрес, по которому с ним можно связаться нетмейлом. 3.1 Признание модераторов Модератор признается следующим образом: 1) При создании конференции модератором становится лицо, создавшее конференцию. 2) При отставке или замене существующего модератора выбор нового модератора определяется решением старого модератора, правилами конференции или (в случае, если воля старого модератора неизвестна, а соответствующий раздел в правилах отсутствует) выборами, проводимыми по методике, описанной в правилах конференции или (при ее отсутствии) по методике, санкционированной REC. В случае, если в результате выборов подписчики не смогли определиться с кандидатурой на пост модератора конференции, она удаляется с регионального бекбона и не может быть вновь принята на него ранее, чем через полгода. 3) В случае длительного (более полугода или иного срока, указанного в правилах конференции) несоблюдения модератором своих обязанностей (см. п. 3.2) модератор смещается. Hовый модератор определяется согласно п. 3.1.2 данного документа. Модераторы перечисляются в cписке конференций бекбона (эхолисте), который является источником всей необходимой информации для хабов. Также рекомендуется перечислять в эхолисте комодераторов. Модератор и комодераторы обязательно должны быть указаны в правилах эхоконференции. Официальный архив правил, используемых при рассмотрении официальными лицами любого конфликта в эхе, ведет REC. Поощряется назначение модераторами комодераторов для помощи и замены модераторов на время отсутствия. 3.2 Обязанности модераторов Модераторы отвечают за следующий круг вопросов: 1) Сообщение REC'у действительного сетевого адреса, по которому к ним можно обратиться через FidoNet, для помещения в эхолист, а также актуальных правил конференции для помещения в официальный архив. 2) Просмотр сообщений в их конференциях на предмет соответствия теме и правилам конференции. 3) Пресечение появления в их конференциях нелегальной информации или содействия нелегальной деятельности. 4) Предоставление информации о тематике конференции и действующих в ней соглашениях (правил) по нетмейловому запросу, а также когда сочтут это необходимым. В целях поддержания порядка модератор может запретить помещение в конференцию сообщений по определенным им критериям - в том числе сообщений на определенную тему, от определенного автора или с определенного адреса. В случае перевода в read-only, то есть получения от модератора запрета помещать сообщения в конференцию, подписчик не имеет права писать в эту конференцию до оговоренного срока ни с какого адреса ни через один узел. В случае нарушения режима read-only пойнтом модератору следует уведомить об этом сисопа узла - в этом случае сисопу следует обеспечить read-only путем проведения разъяснительной работы с пойнтом или с использованием технических средств. В случае нарушения режима read-only сисопом узла (в том числе при необеспечении им режима read-only для пойнта) модератор вправе потребовать отключения узла-нарушителя на аплинке. Такое требование направляется в виде нетмейл-сообщения аплинку данного узла. После проверки наличия модератора в эхолисте аплинк производит отключение. В случае невыполнения аплинком директивы модератора, модератор может потребовать, чтобы в read-only был переведен этот аплинк и т.д. Такое требование оформляется в виде нетмейл-сообщения аплинку, снабжающему аплинка, противодействующего модератору, вместе с копией аплинку, не выполнившему требование модератора. После проверки информации аплинк, противодействующий модератору, отключается от данной конференции. Одновременно модератор информирует REC'а о факте нарушения режима read-only в его конференции. Hевыполнение сисопами узлов требований модератора, касающихся обеспечения режима read-only для отключенных подписчиков, является основанием для подачи REC'ом жалобы в адрес NC узла-нарушителя (или RC,в случае, если узел-нарушитель - независимый узел в регионе), с целью принятия им решения о дальнейшем функционировании данного узла. В случае отсутствия решения NC по данной жалобе в течение 7 дней, соответствующее решение принимает RC. Региональные эхохабы и сетевые лонглинки не могут быть отключены (переведены в режим read-only) от конференции на любом другом узле, с которым они осуществляет обмен данной конференцией, так как это противоречит их статусу, описанному в данном документе, и приведет к нарушению хождения конференции по региональному бекбону. Тем не менее, модератор может потребовать, чтобы сисоп эхохаба или лонглинка перевел эхоконференцию в режим read-only для пользователей своего узла, а сам воздержался от помещения сообщений в конференцию. В случае возникновения конфликта между модератором конференции и сисопом регионального эхохаба, модератор обязан направить соответствующее представление REC. После изучения ситуации REC принимает решение либо о дальнейшем нахождении хаба в составе регионального бекбона, либо о нахождении на нем конфликтной конференции. 4.0 Другие функциональные процедуры 4.1 Технические области REC определяет список и статус эхоконференций, файлэх и других ресурсов, используемых для обеспечения деятельности бекбона, публикации информации о его работе и распространения официальных документов. REC является модератором этих эхоконференций и файлэх. Хабам регионального эхобона, узлам-лонглинкам и модераторам распространяемых в R50 конференций рекомендуется быть подписанными на эти официальные конференции. 4.2 Технические стандарты сообщений Перечень технических требований к конференциям (используемые стандарты и т.д.) определяется REC'ом и распространяется им публично. Бекбон не поддерживает пересылку зашифрованных сообщений (за исключением использования цифровых подписей). Пересылка двоичных файлов в форматах UUENCODE, MIME и т.д. должна регламентироваться правилами конкретной эхоконференции, но в общем случае следует стремиться к снижению такого трафика - например, запретом помещения в конференцию двоичной информации без явного разрешения (ко)модератора. Хабы могут уничтожать сообщения, которые не удовлетворяют техническим стандартам, когда такие сообщения могут нанести вред техническим операциям бекбона. К ним относятся дублированные сообщения, и сообщения в эхопочте с возрастом более 20 дней. Такие сообщения обычно не возвращаются. Хабы функционируют в защищенном режиме. Это означает, что они автоматически обрабатывают сообщения только от тех узлов, с которыми имеются предварительные соглашения. Обычно хабы имеют пароль на сессию и защищенные входные области. Однако приемлем любой другой надежный метод, который обеспечивает отсутствие на бекбоне несанкционированных сообщений. 4.3 Добавление конференций на бекбон Конференция добавляется на бекбон и заносится в список признанных конференций, если выполнены все перечисленные ниже требования: 1) Модератор отправил нетмейловый запрос к REC вместе с правилами своей конференции. 2) Правила конференции допускают написание сообщений на русском языке, согласно им допускается распространение конференции в любой сети R50 и в них оговорен порядок смены модератора, 3) Hи один из сисопов региональных эхохабов не привел аргументированные возражения против принятия эхоконференции на бекбон. При получении заявки REC уведомляет об этом модератора (нетмейлом или сообщением в официальной конференции) и выносит решение о приеме его конференции на эхобон или об отказе в приеме не позднее, чем через один месяц с момента получения заявки. В случае принятия конференции на бон информация об этом публикуется в официальной конференции в течение недели. Существование на бекбоне конференций, аналогичных принимаемой по тематике, не может служить причиной отказа в приеме конференции на бекбон, однако модератор должен четко обосновать необходимость принятия ее на бекбон. Любая временно удаленная с бекбона конференция восстанавливается для регулярного распространения через бекбон, когда ситуация, вызвавшая ее удаление, будет корректно устранена. 4.4 Удаление конференций с бекбона Конференция удаляется с бекбона в одном из перечисленных случаев: 1) Модератор посылает нетмейлом в адрес REC запрос на удаление конференции с бекбона. 2) Модератор не выполняет свои обязанности, как это описано в разделе 3.2, и требования REC 3) Конференция, временно удаленная с бекбона, не была восстановлена для регулярного распространения через бекбон спустя два месяца с момента ее удаления. 4) Большинство региональных эхохабов высказались за удаление конференции с бекбона. REC может снять с бекбона конференции, нарушающие нормальное функционирование бекбона, либо явно не соответствующие Эхополу. Термин "удаление с бекбона" не означает запрета на распространение конференции региональными хабами, либо любыми другими узлами региона. Конференция, удаленная с бекбона, удаляется из списка конференций бекбона, а системные операторы региональных хабов самостоятельно принимают решение о ее дальнейшем распространении или нераспространении их узлами (см. п. 4.7). 4.5 Внешние, межрегиональные и межсетевые конференции Кроме внутрирегиональных конференций бекбон может поддерживать также внешние, межрегиональные или межсетевые конференции. Распространение внутрирегиональных конференций за пределы региона возможно при согласии модератора конференции обеспечивать соблюдение эхополиси региона. Это касается также и гейтования региональных конференций в другие сети. Решение о поддержке внешней конференции региональным бекбоном принимается REC-ом точно так же, как и в случае принятия на бекбон новой конференции. REC может принять решение о поддержке региональным бекбоном внешних конференций, не соответствующих эхополиси региона. При этом должны быть определены процедуры, обеспечивающие нормальное функционирование бекбона. Межрегиональные и межсетевые конференции распространяются по региональному бекбону на основе соглашений REC'ов регионов (или соответствующих ответственных лиц других сетей). При этом должны быть определены процедуры обеспечивающие нормальное функционирование бекбона. 4.6 Финансовые взаимоотношения В необходимых случаях в рамках регионального бекбона (как в целом, так и в отдельных его частях) может вводиться система взаимного возмещения расходов (costsharing). Принципы и порядок функционирования такой системы устанавливаются по взаимной договоренности заинтересованными лицами (лицом, несущим расходы, и лицами, которые получают от него эхопочту). Извлечение прибыли при передаче конференций бекбона от системы к системе не допускается и влечет полное отключение узла от бекбона. 4.7 Конференции вне регионального бекбона Порядок и процедуры распространения конференций, не принятых на региональный эхобон, оговариваются заинтересованными лицами согласно Общему Уставу FidoNet (FidoNet рolicy). 5.0 Порядок разрешения конфликтов В случае нарушения положений данного документа, которые создают угрозу для нормального функционирования регионального бекбона, любой сисоп региона может подать жалобу NEC или REC. При подаче жалоб следует придерживаться следующего порядка. Первым шагом должна быть попытка связи с лицом, допустившим нарушение. Если такие переговоры не дадут желаемого результата, то сисоп может направить жалобу NEC (в рамках сети) и REC, представив копию переписки с нарушителем. REC'ом не принимаются жалобы на санкции, налагаемые модераторами конференций, если они являются внутренним делом конференции и не затрагивают других конференций бекбона. Также не принимаются любые апелляции относительно конференций, распространяемых помимо регионального бекбона. В случае обнаружения дублированных сообщений (dupes) нетмейловое сообщение об этом (с копией служебной информации) должно направляться нетмейлом соответствующему эхокоординатору или бонмастеру. Требования эхокоординатора и бонмастера о разрыве указанного ими линка для устранения дублирования сообщений на бекбоне обязательны для выполнения любым узлом, получающим эхопочту с бекбона. Hевыполнение этих требований или неоднократное создание линков, порождающих дублированные сообщения, являются основанием для подачи REC'ом или бонмастером жалобы в адрес NC узла-нарушителя (или RC, в случае, если узел-нарушитель - независимый узел в регионе) с целью принятия им решения о дальнейшем функционировании данного узла. В случае отсутствия решения NC по данной жалобе в течение 7 дней, соответствующее решение принимает RC. Все конфликты, касающиеся соблюдения Общего Устава FidoNet (FidoNet Policy) должны решаться помимо структуры эхокоординаторов в порядке, предусмотренном FidoNet Policy. 6.0 Порядок принятия и изменения эхополиси 6.1 Принятие эхополиси и переходный период REC и NEC'и, занимающие эти должности в момент принятия данного документа продолжают выполнять свои обязанности в указанном объеме до отставки или замены в соответствии с данным документом. Если в момент принятия документа должность REC окажется вакантной (т.е. существующий REC заявит о своей отставке), то новый REC должен быть назначен региональным координатором в соответствии с процедурой, описанной в п.2.2. В случае отсутствия в момент выборов оформленного регионального бекбона, в выборах принимают участие все системные операторы узлов региона 50. REC определяет и рассылает по официальной файлэхе эхобона R50 структуру и состав регионального бекбона, перечень технических требований к конференциям, а также список конференций регионального бекбона и их модераторов не позже, чем через два месяца после принятия данного документа (или после своего избрания, если в момент принятия документа должность REC была вакантна). Hе позже, чем через четыре месяца после принятия документа (или избрания REC) должен быть разработан и согласован с региональными хабами аварийный план функционирования бекбона (см. п. 2.1 и 2.3). Hевыполнение REC'ом этих требований в указанные сроки является основанием для смещения REC'а до истечения шести месяцев и проведения новых выборов. Процедура формирования регионального бекбона в течении этих двух месяцев (создание списка конференций бекбона и списка региональных хабов) определяется REC, и может отличаться от процедур, описанных в данном документе. 6.2. Внесение изменений в эхополиси Изменения данного документа могут предлагаться RC, REC, NC, NEC и сисопами региональных хабов. Если предлагаемое изменение получит одобрение более 10% от всех NC, NEC, RC, REC и сисопов региональных эхохабов - REC обязан назначить голосование по этому изменению. Голосование по предлагаемым изменениям проводится среди RC, REC, NC, NEC и сисопов региональных хабов по принципу "один человек - один голос". Hовая версия считается принятой, если за изменение проголосует более двух третей от числа лиц, принявших участие в голосовании. Предлагаемые изменения отклоняются, если за их принятие проголосует менее половины от числа лиц, принявших участие в голосовании. В случае, если предлагаемое изменение наберет не менее половины поданных голосов, но и не более двух третей, то для его принятия или отклонения может быть назначено голосование среди всех системных операторов региона. Такое голосование назначается, если на его проведении настаивает человек, предложивший изменение. Изменение принимается, если за него проголосует более 50% системных операторов, принявших участие в голосовании.